Release off of tags - #23

A release now makes itself: a maintainer pushes an annotated or lightweight
version tag, and the workflow creates the GitHub release with generated
notes. Before this, the release was a manual step in the GitHub UI, so the
tag and its release could drift apart.

Create the release only when it does not exist yet, so a re-run of the
workflow does not fail on the tag that already has a release.

Change-Id: Id820c7ca6ea029036a14dda06e258ad9470bd980

A release with no binaries is not a release that a maintainer can hand
to a user who does not build from source. Build Linux and macOS binaries
for arm64 and amd64, then attach them with checksums.

The assets go to a draft first, so a release that still lacks an asset
does not appear in the public list while the upload runs. The publish
job has no checkout, so it sets GH_REPO: gh reads the repository from
the environment, and a job without a work tree has nothing else to read.

A re-run must repair a release that a failed upload left behind, so the
upload step has no condition and overwrites its assets. The create and
the publish steps read the release state first, so a re-run does not
publish twice and does not touch a version that is already public.

Change-Id: I81af424ff328bbe5a33ab29fa976485cdf40671a

The worktree tooling asks for `latest`, but `mise.lock` still held
0.21.0, so every run used the older release. The lock now records the
current release.

Change-Id: If0ce9f775764c099ed435bfbbadca0c15b9ea301